I was thinking of using this PR to tackle also issue #3957. What do people think about it?
@ali-ramadhan @navidcy @glwagner @tomchor

The PartialCellBottom example crashes with this bugfix. I suggest I just revert this PR not to close #3958 and we can tackle that in a new PR if that's ok.

In this PR there is a suggestion to improve the internals following #3957.
The exported functions are only the verbose ones, while the "mathy" ones are left for internal use.
Let me know what you guys think @ali-ramadhan @glwagner @tomchor

The PartialCellBottom example crashes with this bugfix. I suggest I just revert this PR not to close #3958 and we can tackle that in a new PR if that's ok.

Sounds good to me!

In this PR there is a suggestion to improve the internals following #3957. The exported functions are only the verbose ones, while the "mathy" ones are left for internal use. Let me know what you guys think @ali-ramadhan @glwagner @tomchor

I'm also okay with this. Is this a breaking change?

I'm also okay with this. Is this a breaking change?

I think it's not breaking. The metrics that were defined in AbstractOperations to be part of abstract operations are removed in this PR so what was

using Oceananigans.AbstractOperations: Ax
c = CenterField(grid)
cAx = c * Ax

can be done in this PR with

using Oceananigans.Operators: Ax
c = CenterField(grid)
cAx = c * Ax

However, since AbstractOperations imports the metric functions, the first version is still valid, despite the actual objects being different.

What's the advantage of getting rid of xspacing? I guess the idea was that users should use this in forcing functions etc to generate more readable code. Did the original logic behind defining the verbose versions change?

I was thinking of using this PR to tackle also issue #3957. What do people think about it? @ali-ramadhan @navidcy @glwagner @tomchor

Better to have different issues in different PRs, as usual.

What's the advantage of getting rid of xspacing? I guess the idea was that users should use this in forcing functions etc to generate more readable code. Did the original logic behind defining the verbose versions change?

In the end, this PR does not change the user interface, except for adding xarea, yarea, and zarea to be consistent with the verbose spacings. Most of the work is refactoring the internals of the code to make it better organized and extendable which includes:

• use only the Δ* functions in the internal functions and export the *spacing functions for use in scripts where the *spacing function is defined only once in the Operators module as *spacing(args...) = Δ*(args...).
• remove the conflicting definition of Δ* in AbstractOperations since we can use the ones defined in Operators
• remove redundant definitions here and there, for example, Δz does not depend on the (underlying) grid type so define it only once
• Treat Δλ and Δφ as the other spacings (which involves defining the Δλᵃᵇᶜ functions and then the general Δλ(i, j, k, grid, ℓx, ℓy, ℓz) functions)
• move all the spacings definitions to the spacings_and_areas.jl file in the Operators module.